From: Roland P. <pa...@ta...> - 2004-02-24 17:45:15
|
Hi, I am trying to activate grsecurity and find it not so easy to set up a proper acl set for several applications (the learning mode is ok, but still requires lots of work afterwards). I got the acls for various (simple) applications (parts borrowed from debian-secure-acls). Am I the only one who thinks this is a bit annoying? Or is there a public repository for acls that I'm not aware of? If not, why don't we just try to set up a minimal (documented) acl ruleset for every source package in DL and install them (onto the etc-image) when a package is selected in the build system? Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
From: Alex P. <ap...@ap...> - 2005-07-24 22:55:14
|
What's the solution for this problem? The server version of DL is for i686 and my machine is i586 (well I think it's i586, it's a cyrix 233 mhz). So I probably can't use that... (unless I compile everything myself). src@router kernel: grsec: denied resource overstep by requesting 223854592 for RLIMIT_STACK against limit 8388608 for /sbin/killall5[pidof:1242] uid/euid:0/0 gid/egid:0/0, parent /shm/etc/init.d/named[named:765] uid/euid:0/0 gid/egid:0/0 I regularly get dns lookup problems on my client machines... Must be named having memory problems :) Alex |
From: Heiko Z. <he...@zu...> - 2005-07-25 00:17:19
|
On Sun, July 24, 2005 17:55, Alex Prinsier wrote: > What's the solution for this problem? The server version of DL is for > i686 and my machine is i586 (well I think it's i586, it's a cyrix 233 mhz). > So I probably can't use that... (unless I compile everything myself). > > > src@router kernel: grsec: denied resource overstep by requesting 223854592 > for RLIMIT_STACK against limit 8388608 for /sbin/killall5[pidof:1242] > uid/euid:0/0 gid/egid:0/0, parent > /shm/etc/init.d/named[named:765] uid/euid:0/0 gid/egid:0/0 > > > I regularly get dns lookup problems on my client machines... Must be > named having memory problems :) It's very interesting, that killall request 223 MB stack ... If you need a i586 server version, then yes, you'll have to compile it yourself. -- Regards Heiko Zuerker http://www.devil-linux.org |
From: Bradlee L. <bra...@gm...> - 2011-08-19 14:14:15
|
I have multiple Devil Linux's in the field, and I thought I installed them all from the same source, but I'm seeing one that says it is kernel 2.6.32.27-grsec, where as all the others don't have grsec. This is making a line show up in the logs: src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ... Most machines are running 1.4.1, but I only see this one machine with grsec enabled. Why is it turned on here and not elsewhere, did I download a different binary? Or was the 1.4.1 changed at some point? Will having grsec enabled affect programs? -- Thanks, Brad Landis |
From: Dominic R. <dl...@ed...> - 2011-08-19 14:27:37
|
I think grsec is only found in the 'non-server' version of DL. Also Heiko reported there may be some issues with grsec in 1.4.1, probably better to move to current release 1.4.2 (or 1.4.3-testing). HTH Dominic (who only uses DL-server version) On 19/08/2011 15:14, Bradlee Landis wrote: > I have multiple Devil Linux's in the field, and I thought I installed > them all from the same source, but I'm seeing one that says it is > kernel 2.6.32.27-grsec, where as all the others don't have grsec. This > is making a line show up in the logs: > > src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ... > > Most machines are running 1.4.1, but I only see this one machine with > grsec enabled. Why is it turned on here and not elsewhere, did I > download a different binary? Or was the 1.4.1 changed at some point? > Will having grsec enabled affect programs? > |
From: Bradlee L. <bra...@gm...> - 2011-08-19 20:40:51
|
It's a little difficult to update when the servers are 2 states away, and I only go once a year. Luckily, this one is only an hour away, so I can update this one, but we want to get them all to one version. I don't think I can just copy the boot/ files to update, because then it makes some binaries unusable (such as shutdown), and would be catastrophic if it broke the system. Thanks for the help. On Fri, Aug 19, 2011 at 9:26 AM, Dominic Raferd <dl...@ed...> wrote: > I think grsec is only found in the 'non-server' version of DL. Also > Heiko reported there may be some issues with grsec in 1.4.1, probably > better to move to current release 1.4.2 (or 1.4.3-testing). > > HTH > > Dominic (who only uses DL-server version) > > On 19/08/2011 15:14, Bradlee Landis wrote: >> I have multiple Devil Linux's in the field, and I thought I installed >> them all from the same source, but I'm seeing one that says it is >> kernel 2.6.32.27-grsec, where as all the others don't have grsec. This >> is making a line show up in the logs: >> >> src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ... >> >> Most machines are running 1.4.1, but I only see this one machine with >> grsec enabled. Why is it turned on here and not elsewhere, did I >> download a different binary? Or was the 1.4.1 changed at some point? >> Will having grsec enabled affect programs? >> > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > -- Thanks, Brad Landis |
From: Dominic R. <dl...@ed...> - 2011-08-20 06:44:32
|
Well, maybe you don't need to upgrade (if it is all working okay apart from this one mystery message)? More generally, remote upgrade is tricky with DL (which some might see as a good thing). Upgrading via DL's ethernet connection is out because the upgrade process starts before networking does. Possible workarounds that I can think of: * If DL machine is a VM then you can presumably get access to its local screen via the host * Serial port connection (if you have a serial connection from DL machine to another local machine which you then access remotely by SSH/VPN/whatever) * Peppercon Eric Express or similar device which presents the DL machine's local screen as a web page under Java (also allowing local keyboard input). You might pick one up cheaply on eBay? Also (except in VM situation) you probably need a minion locally to do the physical switch-over of CD or flash drive, and in practice this is a must so that you can regress the upgrade if necessary. Dominic On 19/08/11 21:40, Bradlee Landis wrote: > It's a little difficult to update when the servers are 2 states away, > and I only go once a year. Luckily, this one is only an hour away, so > I can update this one, but we want to get them all to one version. > > I don't think I can just copy the boot/ files to update, because then > it makes some binaries unusable (such as shutdown), and would be > catastrophic if it broke the system. > > Thanks for the help. > > On Fri, Aug 19, 2011 at 9:26 AM, Dominic Raferd > <dl...@ed...> wrote: >> I think grsec is only found in the 'non-server' version of DL. Also >> Heiko reported there may be some issues with grsec in 1.4.1, probably >> better to move to current release 1.4.2 (or 1.4.3-testing). >> >> HTH >> >> Dominic (who only uses DL-server version) >> >> On 19/08/2011 15:14, Bradlee Landis wrote: >>> I have multiple Devil Linux's in the field, and I thought I installed >>> them all from the same source, but I'm seeing one that says it is >>> kernel 2.6.32.27-grsec, where as all the others don't have grsec. This >>> is making a line show up in the logs: >>> >>> src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ... >>> >>> Most machines are running 1.4.1, but I only see this one machine with >>> grsec enabled. Why is it turned on here and not elsewhere, did I >>> download a different binary? Or was the 1.4.1 changed at some point? >>> Will having grsec enabled affect programs? >>> >> ------------------------------------------------------------------------------ >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> user administration capabilities and model configuration. Take >> the hassle out of deploying and managing Subversion and the >> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 >> _______________________________________________ >> Devil-linux-discuss mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss >> > > |
From: Serge L. <ser...@gm...> - 2011-08-23 01:10:38
|
Hi Dominic, On 08/19/2011 11:44 PM, Dominic Raferd wrote: .. > More generally, remote upgrade is tricky with DL (which some might see > as a good thing). I'm afraid you are right.... I spent some time thinking how we can improve the situation and now I'd like to share my idea (and code, if volunteers exist) for the system designed with security and 'recoverability' in mind (i.e. image and configs are the only things which are necessary to recover the system) we should be able to have more than one Boot Environment (BE, image + configs) for really fast rollbacks. The consequences from the statement above are: - CDROM as a primary image source is not vital anymore, because it's a paint to change/swap disks in it. I guess this is fine, because almost everybody uses flash-drives now. - we have to distinguish different BEs, i.e. instead of counting on auto-search we should be able to identify where those files are. I'd suggest using the following addition to the kernel boot parameters: image=<BLOCK_DEVICE>,</PATH>,<NAME> configs=<BLOCK_DEVICE>,</PATH>,<NAME> it allows to have configs and images on different partitions or on different devices and have all images/configs in different directories. I'd also wold like to have an ability to rename those files. - <BLOCK_DEVICE> can be identified as a device name, as a FS LABEL or UUID (see blkid output). I personally prefer to use UUID to be immune to volatile device names. - The only boot-loader I know (which is capable to work with UUID and understands a lot of filesystem) is grub2 :). So, in general it looks like we have a boot loader (grub2) menu, where we can choose BE. DL update is equivalent of an additional BE creating, rollback is equivalent of reboot into different BE. I believe it will simplify the upgrade and rollbacks and make remote management a bit less tricky. Serge |
From: Andrzej O. <an...@ma...> - 2011-08-23 11:05:47
|
Dears, Serge Leschinsky wrote: > - we have to distinguish different BEs, i.e. instead of counting on auto-search So I'm identyfying boot image using version id. This is working on my over ten remote DL installations. Auto-search check version on image with version on initrd. On near all instalations I have two or more boot devices. On each boot partition I append unique suffix to version id, i.e. -SD, -HD, -SSD to find proper image for boot. But boot device is selected via BIOS. so, if there is a problem with boot from one device, I connect to remote console via Intel AMT technology and change BIOS settings. > I'd suggest using the following addition to > the kernel boot parameters: image=<BLOCK_DEVICE>,</PATH>,<NAME> > configs=<BLOCK_DEVICE>,</PATH>,<NAME> But for use kernel boot parameters, You need remote console access too. > - The only boot-loader I know (which is capable to work with UUID and > understands a lot of filesystem) is grub2 :). Unfortunately, Intel AMT technology use serial with semi-random i/o port, and the only boot-loader with possibility to set serial console i/o port is syslinux. Autodetect of this i/o port is complicated, and not supported via boot-loaders. In kernel this is relatively big code. Because of this I use syslinux only. > So, in general it looks like we have a boot loader (grub2) menu, where we can > choose BE if we have remote access to grub menu. The only cheap method to remote access I know is Intel AMT. Can You suggest another? Regards Andrzej Odyniec |
From: Serge L. <ser...@gm...> - 2011-08-23 19:20:50
|
Andrzej, On 08/23/2011 04:05 AM, Andrzej Odyniec wrote: > Dears, > > Serge Leschinsky wrote: >> - we have to distinguish different BEs, i.e. instead of counting on auto-search > > So I'm identyfying boot image using version id. This is working on my over ten remote DL > installations. Auto-search check version on image with version on initrd. On near all instalations > I have two or more boot devices. On each boot partition I append unique suffix to version id, i.e. > -SD, -HD, -SSD to find proper image for boot. So, you identify the proper image specifying the different name. OK. What about configs? Do you have the same trick for the configuration file? > But boot device is selected via BIOS. so, if there is a problem with boot from one device, I > connect to remote console via Intel AMT technology and change BIOS settings. That's fine. I don't see any problem to have more than one boot device. However, I'd prefer to get the loader config files synchronized. Maybe install loader on RAID1. > >> I'd suggest using the following addition to >> the kernel boot parameters: image=<BLOCK_DEVICE>,</PATH>,<NAME> >> configs=<BLOCK_DEVICE>,</PATH>,<NAME> > > But for use kernel boot parameters, You need remote console access too. Hmm.... Probably I don't completely understand you. Yes, to update DL I have to have an access to the system. Somehow. ssh or serial or SOL (serial over lan) or something else. In essence my idea was to modify boot loader config file every time I update DL - merely create an additional record there to simplify rollback. I suppose I'd add this records with "boot once" option, to be able to load the previous BE in case of inability to boot (and reset the box by power). However, I still need an access at least for power management. > >> - The only boot-loader I know (which is capable to work with UUID and >> understands a lot of filesystem) is grub2 :). > > Unfortunately, Intel AMT technology use serial with semi-random i/o port, and the only boot-loader > with possibility to set serial console i/o port is syslinux. Autodetect of this i/o port is > complicated, and not supported via boot-loaders. In kernel this is relatively big code. Because of > this I use syslinux only. I don't think it's critical what loader to use. I like grub2 because it can do everything I need - boot from LVM, from RAID, recognize XFS and BTRFS. Text mode and serial console are also exist, but probably not so fully as in syslinux. I'm not sure if bootchain can help in your case, but nobody prevents from using syslinux instead on grub2. > >> So, in general it looks like we have a boot loader (grub2) menu, where we can >> choose BE > > if we have remote access to grub menu. The only cheap method to remote access I know is Intel AMT. > Can You suggest another? ip-kvm, hardware serial console or SOL (aka Intel AMT, ipmi or iLOM). Sincerely, Serge |
From: Andrzej O. <an...@ma...> - 2011-08-24 11:30:18
|
Serge, You wrote: > So, you identify the proper image specifying the different name. OK. What about > configs? Do you have the same trick for the configuration file? No. As for now, I'm not identyfying config file according to used boot image. I'm using this from auto-search. The only difference is inversion of question about wrong config file version (if boot image is new) - script is waiting one minute (not 5) and after no answer wrong config is accepted without interactive conversion. Main is to make up remote system. Rest we can do via ssh. Ofcourse as last before last resort we can use DL_config kernel parameter. And absolute last resort is remote boot from remote redirected CD small diagnostic linux. >From this linux I can do wget on new image and install it using modified install-on-usb script working on busybox. Multiple boot is for me as reserve for bad new DL image or broken one of boot source. I do not alternate switched/convertible system. So typically I don't need alternate configs. > That's fine. I don't see any problem to have more than one boot device. However, > I'd prefer to get the loader config files synchronized. Maybe install loader on > RAID1. RAID solves only broken boot device problem. Problem with not booting new DL image in particular remote context is not solved by RAID. So I need possibility to boot from old working image if new image in this remote contaxt is broken (even if it was tested on table). Imagine remote departament router not booting after upgrade... Next day router must be working. But if remote site is 400km from us?... > Hmm.... Probably I don't completely understand you. Yes, to update DL I have to > have an access to the system. Somehow. ssh or serial or SOL (serial over lan) or something else. In > essence my idea was to modify boot loader config file every time I update DL - merely create an > additional record there to simplify rollback. I suppose I'd add this records with "boot once" > option, to be able to load the previous BE in case of inability to boot (and reset the box by > power). However, I still need an access at least for power management. Boot how You will prefa > > > >> >>> - The only boot-loader I know (which is capable to work with UUID and >>> understands a lot of filesystem) is grub2 :). >> >> Unfortunately, Intel AMT technology use serial with semi-random i/o port, and the only >> boot-loader with possibility to set serial console i/o port is syslinux. Autodetect of this i/o >> port is complicated, and not supported via boot-loaders. In kernel this is relatively big code. >> Because of >> this I use syslinux only. > > I don't think it's critical what loader to use. I like grub2 because it can do > everything I need - boot from LVM, from RAID, recognize XFS and BTRFS. Text mode and serial console > are also exist, but probably not so fully as in syslinux. I'm not sure if bootchain can help in > your case, but nobody prevents from using syslinux instead on grub2. > > >> >>> So, in general it looks like we have a boot loader (grub2) menu, where we can >>> choose BE >> >> if we have remote access to grub menu. The only cheap method to remote access I know is Intel >> AMT. >> Can You suggest another? >> > > ip-kvm, hardware serial console or SOL (aka Intel AMT, ipmi or iLOM). > > > Sincerely, > Serge > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take the hassle out of deploying and > managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > > -- Andrzej Odyniec <an...@ma...> Rada Nadzorcza Macrologic SA ul. Kłopotowskiego 22, 03-717 Warszawa tel. +48-222566332, kom. +48-601276572 Skype: andrzej.odyniec Rejestr: Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego, numer 0000045462 Numer identyfikacji podatkowej: PL 5220002825 Kapitał zakładowy: 1888719 zł opłacony w całości |
From: Andrzej O. <an...@ma...> - 2011-08-24 11:52:04
|
Serge, Sorry for uncomplete previous answer. I will continue. You wrote: > Hmm.... Probably I don't completely understand you. Yes, to update DL I have to > have an access to the system. Somehow. ssh or serial or SOL (serial over lan) or something else. In > essence my idea was to modify boot loader config file every time I update DL - merely create an > additional record there to simplify rollback. I suppose I'd add this records with "boot once" > option, to be able to load the previous BE in case of inability to boot (and reset the box by > power). However, I still need an access at least for power management. But how You will prefabricate proper, dedicated, config for newly installed boot image even if you will associate config with boot immediately on kernel params. > I don't think it's critical what loader to use. I like grub2 because it can do > everything I need - boot from LVM, from RAID, recognize XFS and BTRFS. > Text mode and serial console > are also exist, but probably not so fully as in syslinux. I'm not sure if bootchain can help in > your case, but nobody prevents from using syslinux instead on grub2. My try with grub was unsuccesfull in connection with Intel AMT. >> if we have remote access to grub menu. The only cheap method to remote access I know is Intel >> AMT. >> Can You suggest another? >> > > ip-kvm, hardware serial console or SOL (aka Intel AMT, ipmi or iLOM). Serge, I asked about cheap solution. Only Intel AMT SOL is built into MB and don't need separate hardware. But AMT SOL is to hard to cooperate with grub, so I use syslinux. Best Regards -- Andrzej Odyniec |