Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2017-02-20 15:29:15
|
Hi David, I'm not a big fan if 'git', but GitHub is great. We use the SVN revision number in our release labeling, I was already investigating how not having a monotonically increasing number would effect us. GitHub does have some sort of SVN wrapper, but if we ever went that route, probably best we bite the 'git' bullet. BTW, given how the Sourceforge SVN error reacts, and the fact the AstLinux repository is readable, it could be a big-iron router issue, not the repo itself. Regardless, it is insane that their https://twitter.com/sfnet_ops says everything is A OK. Lonnie On Feb 20, 2017, at 9:11 AM, David Kerr <da...@ke...> wrote: > There are dozens of tickets open starting saturday... https://sourceforge.net/p/forge/site-support/ > Not one of them has any response yet. > Feels to me like a sev 1 problem that should have got attention long ago. > Both svn and git problem reports. > > Not good. Maybe we should move astlinux to github. Okay, maybe I overreact for just one incident !! > > David > > > On Mon, Feb 20, 2017 at 9:56 AM, David Kerr <da...@ke...> wrote: > Me too.... has been like this since yesterday at least. > > David > > On Mon, Feb 20, 2017 at 4:19 AM, Michael Keuter <li...@mk...> wrote: > > > Am 20.02.2017 um 07:47 schrieb Armin Tüting <arm...@tu...>: > > > > Hi Devs, > > > > is it just me experiencing the issue? > > > > svn update > > Updating '.': > > svn: E000111: Unable to connect to a repository at URL > > 'svn://svn.code.sf.net/p/astlinux/code/branches/1.0' > > svn: E000111: Can't connect to host 'svn.code.sf.net': Connection > > refused > > Yes, I see the same. > Sourceforge seems to have problems. > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-20 15:16:14
|
> I'm curious... will this also restrict access to busybox built-in commands? Yes, only the symlinks/scripts in the /usr/rbin/ directory (listed below) are allowed. Also /mnt/kd/rbin/ if it exists. I was able to create a 'grep' wrapper limited to stdin use, so when Sourceforge is back up I'll commit that. BTW, the bash built-in commands are available under rbash. Lonnie On Feb 20, 2017, at 9:01 AM, David Kerr <Da...@Ke...> wrote: > I'm curious... will this also restrict access to busybox built-in commands? > > Thanks > David > > On Sat, Feb 18, 2017 at 10:05 PM, Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > We put together some documentation for the new Restricted User Login feature ... > > Restricted User Login > https://doc.astlinux-project.org/userdoc:tt_restricted_user_login > > BTW, this new feature seems to work quite well. > > Currently the available commands are: > -- > arp df host iftop mtr ping ss traceroute6 whoami > clear fping htop ip netstat ping6 top uname whois > date fping6 ifconfig ls nslookup ps traceroute uptime > -- > > Imagine for yourself, you have a non-technical user at the other end of the phone, issuing any of the above "safe" commands to try to isolate a problem. > > Can anyone think of any "safe" commands not included above ? > > One fundamental rule for our restricted shell is no files can be created, edited or viewed. > > While using the 'ss' or 'netstat' commands I often pipe to 'grep', but grep can be easily used to view files. We could build some sort of wrapper for grep to only allow stdin and not files. Would some sort of 'safe' grep be useful or is that beyond the scope of most restricted shell users ? > > Lonnie > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2017-02-20 15:11:51
|
There are dozens of tickets open starting saturday... https://sourceforge.net/p/forge/site-support/ Not one of them has any response yet. Feels to me like a sev 1 problem that should have got attention long ago. Both svn and git problem reports. Not good. Maybe we should move astlinux to github. Okay, maybe I overreact for just one incident !! David On Mon, Feb 20, 2017 at 9:56 AM, David Kerr <da...@ke...> wrote: > Me too.... has been like this since yesterday at least. > > David > > On Mon, Feb 20, 2017 at 4:19 AM, Michael Keuter <li...@mk...> > wrote: > >> >> > Am 20.02.2017 um 07:47 schrieb Armin Tüting < >> arm...@tu...>: >> > >> > Hi Devs, >> > >> > is it just me experiencing the issue? >> > >> > svn update >> > Updating '.': >> > svn: E000111: Unable to connect to a repository at URL >> > 'svn://svn.code.sf.net/p/astlinux/code/branches/1.0' >> > svn: E000111: Can't connect to host 'svn.code.sf.net': Connection >> > refused >> >> Yes, I see the same. >> Sourceforge seems to have problems. >> >> Michael >> >> http://www.mksolutions.info >> >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to >> pa...@kr.... > > > |
|
From: David K. <da...@ke...> - 2017-02-20 15:02:27
|
I'm curious... will this also restrict access to busybox built-in commands? Thanks David On Sat, Feb 18, 2017 at 10:05 PM, Lonnie Abelbeck <li...@lo... > wrote: > Hi Devs, > > We put together some documentation for the new Restricted User Login > feature ... > > Restricted User Login > https://doc.astlinux-project.org/userdoc:tt_restricted_user_login > > BTW, this new feature seems to work quite well. > > Currently the available commands are: > -- > arp df host iftop mtr ping > ss traceroute6 whoami > clear fping htop ip netstat ping6 > top uname whois > date fping6 ifconfig ls nslookup ps > traceroute uptime > -- > > Imagine for yourself, you have a non-technical user at the other end of > the phone, issuing any of the above "safe" commands to try to isolate a > problem. > > Can anyone think of any "safe" commands not included above ? > > One fundamental rule for our restricted shell is no files can be created, > edited or viewed. > > While using the 'ss' or 'netstat' commands I often pipe to 'grep', but > grep can be easily used to view files. We could build some sort of wrapper > for grep to only allow stdin and not files. Would some sort of 'safe' grep > be useful or is that beyond the scope of most restricted shell users ? > > Lonnie > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > |
|
From: David K. <da...@ke...> - 2017-02-20 14:56:54
|
Me too.... has been like this since yesterday at least. David On Mon, Feb 20, 2017 at 4:19 AM, Michael Keuter <li...@mk...> wrote: > > > Am 20.02.2017 um 07:47 schrieb Armin Tüting < > arm...@tu...>: > > > > Hi Devs, > > > > is it just me experiencing the issue? > > > > svn update > > Updating '.': > > svn: E000111: Unable to connect to a repository at URL > > 'svn://svn.code.sf.net/p/astlinux/code/branches/1.0' > > svn: E000111: Can't connect to host 'svn.code.sf.net': Connection > > refused > > Yes, I see the same. > Sourceforge seems to have problems. > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Michael K. <li...@mk...> - 2017-02-20 09:19:11
|
> Am 20.02.2017 um 07:47 schrieb Armin Tüting <arm...@tu...>: > > Hi Devs, > > is it just me experiencing the issue? > > svn update > Updating '.': > svn: E000111: Unable to connect to a repository at URL > 'svn://svn.code.sf.net/p/astlinux/code/branches/1.0' > svn: E000111: Can't connect to host 'svn.code.sf.net': Connection > refused Yes, I see the same. Sourceforge seems to have problems. Michael http://www.mksolutions.info |
|
From: Armin T. <arm...@tu...> - 2017-02-20 07:03:58
|
Hi Devs, is it just me experiencing the issue? svn update Updating '.': svn: E000111: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/astlinux/code/branches/1.0' svn: E000111: Can't connect to host 'svn.code.sf.net': Connection refused |
|
From: Michael K. <mic...@ip...> - 2017-02-19 04:33:42
|
Ps. Thanks for doing this. Great feature! Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Sunday, 19 February 2017 at 2:05 PM To: AstLinux Developers Mailing List <ast...@li...> Subject: [Astlinux-devel] Restricted User Login Commands Hi Devs, We put together some documentation for the new Restricted User Login feature ... Restricted User Login https://doc.astlinux-project.org/userdoc:tt_restricted_user_login BTW, this new feature seems to work quite well. Currently the available commands are: -- arp df host iftop mtr ping ss traceroute6 whoami clear fping htop ip netstat ping6 top uname whois date fping6 ifconfig ls nslookup ps traceroute uptime -- Imagine for yourself, you have a non-technical user at the other end of the phone, issuing any of the above "safe" commands to try to isolate a problem. Can anyone think of any "safe" commands not included above ? One fundamental rule for our restricted shell is no files can be created, edited or viewed. While using the 'ss' or 'netstat' commands I often pipe to 'grep', but grep can be easily used to view files. We could build some sort of wrapper for grep to only allow stdin and not files. Would some sort of 'safe' grep be useful or is that beyond the scope of most restricted shell users ? Lonnie ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2017-02-19 04:33:11
|
Hi Lonnie Well my use case is actually technical users so I guess it would be handy but I don't think its mandatory. I think you can do some filtering with the ss command. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Sunday, 19 February 2017 at 2:05 PM To: AstLinux Developers Mailing List <ast...@li...> Subject: [Astlinux-devel] Restricted User Login Commands Hi Devs, We put together some documentation for the new Restricted User Login feature ... Restricted User Login https://doc.astlinux-project.org/userdoc:tt_restricted_user_login BTW, this new feature seems to work quite well. Currently the available commands are: -- arp df host iftop mtr ping ss traceroute6 whoami clear fping htop ip netstat ping6 top uname whois date fping6 ifconfig ls nslookup ps traceroute uptime -- Imagine for yourself, you have a non-technical user at the other end of the phone, issuing any of the above "safe" commands to try to isolate a problem. Can anyone think of any "safe" commands not included above ? One fundamental rule for our restricted shell is no files can be created, edited or viewed. While using the 'ss' or 'netstat' commands I often pipe to 'grep', but grep can be easily used to view files. We could build some sort of wrapper for grep to only allow stdin and not files. Would some sort of 'safe' grep be useful or is that beyond the scope of most restricted shell users ? Lonnie ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-19 03:05:08
|
Hi Devs, We put together some documentation for the new Restricted User Login feature ... Restricted User Login https://doc.astlinux-project.org/userdoc:tt_restricted_user_login BTW, this new feature seems to work quite well. Currently the available commands are: -- arp df host iftop mtr ping ss traceroute6 whoami clear fping htop ip netstat ping6 top uname whois date fping6 ifconfig ls nslookup ps traceroute uptime -- Imagine for yourself, you have a non-technical user at the other end of the phone, issuing any of the above "safe" commands to try to isolate a problem. Can anyone think of any "safe" commands not included above ? One fundamental rule for our restricted shell is no files can be created, edited or viewed. While using the 'ss' or 'netstat' commands I often pipe to 'grep', but grep can be easily used to view files. We could build some sort of wrapper for grep to only allow stdin and not files. Would some sort of 'safe' grep be useful or is that beyond the scope of most restricted shell users ? Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-02-15 17:49:37
|
iftop is now part of the allowed rbash commands ... https://sourceforge.net/p/astlinux/code/8162/ https://sourceforge.net/p/astlinux/code/8163/ Ideally iftop could use libcap 'cap_net_raw+ep' capabilities instead if setuid, might be a fun project for someone here to create an iftop patch for that. Lonnie On Feb 15, 2017, at 9:28 AM, Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > >> A tool I find useful that may also be appropriate for a restricted shell is iftop, and I like htop too. > > htop is available in /usr/rbin > > but iftop requires root permissions > -- > pcap_open_live(eth0): eth0: You don't have permission to capture on that device (socket: Operation not permitted) > -- > > Though, like fping we could consider adding root setuid for iftop. At one time iftop allowed a ! escape to a shell, but that is no longer enabled with a ALLOW_SUBSHELL #define (not defined). > > Thoughts ? > > Lonnie > > > On Feb 15, 2017, at 8:57 AM, David Kerr <Da...@Ke...> wrote: > >> A tool I find useful that may also be appropriate for a restricted shell is iftop, and I like htop too. >> >>>> Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. >>> >>> PS: David, see if you can break out :-) >> >> Ah, but back then I had much more free time and all-night coding sessions were cool. Besides, I'm quite sure that system security is way better than it was when I was young. >> >> David >> >> >> >> On Tue, Feb 14, 2017 at 1:11 PM, Lonnie Abelbeck <li...@lo...> wrote: >> Update, >> >> I committed rbash support, it went in quite cleanly. >> https://sourceforge.net/p/astlinux/code/8161/ >> >> A non-root user with /bin/rbash shell can be accessed via the CLI tab, ssh session, and console tty. >> >> Obviously this needs testing. >> >>> If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. >> >> After studying the bash code, a one-line patch fixes the sshd problem by setting PATH just before it makes it read-only for restricted mode. This is more secure as well since this eliminates contorted efforts to redefine PATH. >> >> Probably not a general solution for bash (though a --with-rbash-PATH= configure option would be nice), but exactly what we want for an appliance. >> >> >> The initial default 'safe' commands are: >> ============== >> pbx4 [staff] $ ls -1 /usr/rbin/ >> arp >> clear >> date >> df >> fping >> fping6 >> host >> htop >> ifconfig >> ip >> ls >> netstat >> nslookup >> ping >> ping6 >> ps >> pwd >> ss >> top >> traceroute >> traceroute6 >> uname >> uptime >> whoami >> whois >> ============== >> >> Lonnie >> >>> Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. >> >> PS: David, see if you can break out :-) >> >> >> >> On Feb 13, 2017, at 11:14 PM, Lonnie Abelbeck <li...@lo...> wrote: >> >>> Devs, >>> >>> I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in CLI tab, ssh session, and console tty. >>> >>> The only issue is "ssh staff@pbx remote_command", the remote_command is executed under /bin/rbash but not with the desired $PATH. >>> >>> If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. >>> >>> If only there was a /etc/ssh/sshd_config option to ignore any passed remote_command for "Match User staff". >>> >>> Hmmm... >>> >>> Lonnie >>> >>> >>> On Feb 13, 2017, at 4:24 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> +1 from me (obviously) And I can add and remove users/executables if required. >>>> >>>> Maybe a couple of others: >>>> traceroute >>>> nslookup >>>> arp >>>> >>>> I wont have the need for ls or the ability to read files, basically just network and system tools. >>>> Others may have different requirements? >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Michael Keuter <li...@mk...> >>>> Reply-To: AstLinux Developers Mailing List <ast...@li...> >>>> Date: Tuesday, 14 February 2017 at 9:01 AM >>>> To: AstLinux Developers Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-devel] Restricting access to partners >>>> >>>> Hi Lonnie, >>>> >>>> I really like the idea with rbash. I also would have uses for that. >>>> Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. >>>> >>>> Sent from a mobile device. >>>> >>>> Michael Keuter >>>> >>>>> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: >>>>> >>>>> Hi Michael, >>>>> >>>>> I've been playing with rbash, and I think this could be generally useful for us. >>>>> >>>>> I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. >>>>> >>>>> The root user could add a 'rbash' user 'staff' >>>>> -- >>>>> adduser -s /bin/rbash staff >>>>> -- >>>>> >>>>> The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: >>>>> -- >>>>> PATH=/usr/rbin:/mnt/kd/rbin >>>>> -- >>>>> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. >>>>> >>>>> Then the /usr/rbin directory could contain symlinks for: >>>>> -- >>>>> /bin/ls >>>>> /bin/netstat >>>>> /bin/ping >>>>> /bin/uname >>>>> >>>>> /usr/bin/clear >>>>> /usr/bin/htop >>>>> /usr/bin/top >>>>> >>>>> /sbin/ifconfig >>>>> /sbin/ip >>>>> /sbin/ss >>>>> >>>>> /usr/sbin/fping >>>>> /usr/sbin/iftop >>>>> -- >>>>> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? >>>>> >>>>> This should go in quite cleanly, mostly build system stuff. >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>>>> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Hi thanks Lonnie >>>>>> >>>>>> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >>>>>> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >>>>>> Having the symlink in build will mean I don't need to do it so Im interested ☺ >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>> Reply-To: AstLinux Developers Mailing List <ast...@li...> >>>>>> Date: Tuesday, 14 February 2017 at 2:14 AM >>>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>>> Subject: Re: [Astlinux-devel] Restricting access to partners >>>>>> >>>>>> A couple thoughts ... >>>>>> >>>>>> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >>>>>> >>>>>> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >>>>>> >>>>>> >>>>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>>>>> Is this reasonable easy to do? >>>>>> >>>>>> 2) Bash can be restricted ... >>>>>> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >>>>>> >>>>>> But can be escaped as well >>>>>> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >>>>>> >>>>>> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >>>>>> >>>>>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >>>>>> >>>>>> >>>>>> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >>>>>> >>>>>> >>>>>> Lonnie >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>>>>>> >>>>>>> Hi Devs >>>>>>> >>>>>>> I now have a small business partner who is rolling out my systems. >>>>>>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>>>>>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>>>>>> From what I see, there are a couple of options: >>>>>>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>>>>>> 2) Add or use a restricted shell – Im not sure how to do this >>>>>>> 3) Some other idea >>>>>>> >>>>>> >>>>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>>>>> Is this reasonable easy to do? >>>>>> >>>>>>> I would love some ideas. >>>>>>> Thanks so much. >>>>>>> >>>>>>> Regards >>>>>>> Michael Knill >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-15 17:19:33
|
More on Sourceforge emails... I noticed my emails had a bunch of HTML junk in them, the reason is I had "Text" email format chosen. So until they fix the "Text" email format, you can switch to "Combined" https://sourceforge.net/auth/subscriptions/ Email Format: [ Combined ] Lonnie On Feb 13, 2017, at 8:05 AM, Lonnie Abelbeck <li...@lo...> wrote: > Followup, > > It appears previously Sourceforge offered a "astlinux-commits" mailing list, this list is no longer being added to by Sourceforge. > > As noted below, this line ... > -- > AstLinux Code Everything (check) > -- > should appear on this page to receive AstLinux code commit emails: > https://sourceforge.net/auth/subscriptions/ > > Alternatively, while logged into your Sourceforge account, you can go to this link: > > https://sourceforge.net/p/astlinux/code/HEAD/tree/ > > Notice the little "envelope" icon to the right of "History" ... > > <envelope.png> > > Clicking on the "envelope" icon will toggle subscribing to AstLinux code commit emails or not. > > Lonnie > > > On Feb 12, 2017, at 8:38 AM, Lonnie Abelbeck <li...@lo...> wrote: > >> Hi Devs, >> >> If you were previously subscribed to Sourceforge's "AstLinux - Code" to receive commit emails, it stopped working a few days ago, and you need to re-subscribe (checkbox and {Save}) to get commit emails. >> >> https://sourceforge.net/auth/subscriptions/ >> >> BTW, the commit emails are of a very different format (more like GitHub's now). >> >> Lonnie > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-15 15:28:27
|
Hi David, > A tool I find useful that may also be appropriate for a restricted shell is iftop, and I like htop too. htop is available in /usr/rbin but iftop requires root permissions -- pcap_open_live(eth0): eth0: You don't have permission to capture on that device (socket: Operation not permitted) -- Though, like fping we could consider adding root setuid for iftop. At one time iftop allowed a ! escape to a shell, but that is no longer enabled with a ALLOW_SUBSHELL #define (not defined). Thoughts ? Lonnie On Feb 15, 2017, at 8:57 AM, David Kerr <Da...@Ke...> wrote: > A tool I find useful that may also be appropriate for a restricted shell is iftop, and I like htop too. > > >> Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. > > > >PS: David, see if you can break out :-) > > Ah, but back then I had much more free time and all-night coding sessions were cool. Besides, I'm quite sure that system security is way better than it was when I was young. > > David > > > > On Tue, Feb 14, 2017 at 1:11 PM, Lonnie Abelbeck <li...@lo...> wrote: > Update, > > I committed rbash support, it went in quite cleanly. > https://sourceforge.net/p/astlinux/code/8161/ > > A non-root user with /bin/rbash shell can be accessed via the CLI tab, ssh session, and console tty. > > Obviously this needs testing. > > > If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. > > After studying the bash code, a one-line patch fixes the sshd problem by setting PATH just before it makes it read-only for restricted mode. This is more secure as well since this eliminates contorted efforts to redefine PATH. > > Probably not a general solution for bash (though a --with-rbash-PATH= configure option would be nice), but exactly what we want for an appliance. > > > The initial default 'safe' commands are: > ============== > pbx4 [staff] $ ls -1 /usr/rbin/ > arp > clear > date > df > fping > fping6 > host > htop > ifconfig > ip > ls > netstat > nslookup > ping > ping6 > ps > pwd > ss > top > traceroute > traceroute6 > uname > uptime > whoami > whois > ============== > > Lonnie > > > Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. > > PS: David, see if you can break out :-) > > > > On Feb 13, 2017, at 11:14 PM, Lonnie Abelbeck <li...@lo...> wrote: > > > Devs, > > > > I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in CLI tab, ssh session, and console tty. > > > > The only issue is "ssh staff@pbx remote_command", the remote_command is executed under /bin/rbash but not with the desired $PATH. > > > > If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. > > > > If only there was a /etc/ssh/sshd_config option to ignore any passed remote_command for "Match User staff". > > > > Hmmm... > > > > Lonnie > > > > > > On Feb 13, 2017, at 4:24 PM, Michael Knill <mic...@ip...> wrote: > > > >> +1 from me (obviously) And I can add and remove users/executables if required. > >> > >> Maybe a couple of others: > >> traceroute > >> nslookup > >> arp > >> > >> I wont have the need for ls or the ability to read files, basically just network and system tools. > >> Others may have different requirements? > >> > >> Regards > >> Michael Knill > >> > >> -----Original Message----- > >> From: Michael Keuter <li...@mk...> > >> Reply-To: AstLinux Developers Mailing List <ast...@li...> > >> Date: Tuesday, 14 February 2017 at 9:01 AM > >> To: AstLinux Developers Mailing List <ast...@li...> > >> Subject: Re: [Astlinux-devel] Restricting access to partners > >> > >> Hi Lonnie, > >> > >> I really like the idea with rbash. I also would have uses for that. > >> Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. > >> > >> Sent from a mobile device. > >> > >> Michael Keuter > >> > >>> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: > >>> > >>> Hi Michael, > >>> > >>> I've been playing with rbash, and I think this could be generally useful for us. > >>> > >>> I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. > >>> > >>> The root user could add a 'rbash' user 'staff' > >>> -- > >>> adduser -s /bin/rbash staff > >>> -- > >>> > >>> The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: > >>> -- > >>> PATH=/usr/rbin:/mnt/kd/rbin > >>> -- > >>> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. > >>> > >>> Then the /usr/rbin directory could contain symlinks for: > >>> -- > >>> /bin/ls > >>> /bin/netstat > >>> /bin/ping > >>> /bin/uname > >>> > >>> /usr/bin/clear > >>> /usr/bin/htop > >>> /usr/bin/top > >>> > >>> /sbin/ifconfig > >>> /sbin/ip > >>> /sbin/ss > >>> > >>> /usr/sbin/fping > >>> /usr/sbin/iftop > >>> -- > >>> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? > >>> > >>> This should go in quite cleanly, mostly build system stuff. > >>> > >>> Lonnie > >>> > >>> > >>> > >>>> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: > >>>> > >>>> Hi thanks Lonnie > >>>> > >>>> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. > >>>> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. > >>>> Having the symlink in build will mean I don't need to do it so Im interested ☺ > >>>> > >>>> Regards > >>>> Michael Knill > >>>> > >>>> -----Original Message----- > >>>> From: Lonnie Abelbeck <li...@lo...> > >>>> Reply-To: AstLinux Developers Mailing List <ast...@li...> > >>>> Date: Tuesday, 14 February 2017 at 2:14 AM > >>>> To: AstLinux Developers Mailing List <ast...@li...> > >>>> Subject: Re: [Astlinux-devel] Restricting access to partners > >>>> > >>>> A couple thoughts ... > >>>> > >>>> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. > >>>> > >>>> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. > >>>> > >>>> > >>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. > >>>>> Is this reasonable easy to do? > >>>> > >>>> 2) Bash can be restricted ... > >>>> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html > >>>> > >>>> But can be escaped as well > >>>> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells > >>>> > >>>> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. > >>>> > >>>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. > >>>> > >>>> > >>>> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. > >>>> > >>>> > >>>> Lonnie > >>>> > >>>> > >>>> > >>>>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: > >>>>> > >>>>> Hi Devs > >>>>> > >>>>> I now have a small business partner who is rolling out my systems. > >>>>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. > >>>>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. > >>>>> From what I see, there are a couple of options: > >>>>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience > >>>>> 2) Add or use a restricted shell – Im not sure how to do this > >>>>> 3) Some other idea > >>>>> > >>>> > >>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. > >>>>> Is this reasonable easy to do? > >>>> > >>>>> I would love some ideas. > >>>>> Thanks so much. > >>>>> > >>>>> Regards > >>>>> Michael Knill > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2017-02-15 14:57:41
|
A tool I find useful that may also be appropriate for a restricted shell is iftop, and I like htop too. >> Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. > >PS: David, see if you can break out :-) Ah, but back then I had much more free time and all-night coding sessions were cool. Besides, I'm quite sure that system security is way better than it was when I was young. David On Tue, Feb 14, 2017 at 1:11 PM, Lonnie Abelbeck <li...@lo...> wrote: > Update, > > I committed rbash support, it went in quite cleanly. > https://sourceforge.net/p/astlinux/code/8161/ > > A non-root user with /bin/rbash shell can be accessed via the CLI tab, ssh > session, and console tty. > > Obviously this needs testing. > > > If only we could set a compile time option to bash to force > PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. > > After studying the bash code, a one-line patch fixes the sshd problem by > setting PATH just before it makes it read-only for restricted mode. This is > more secure as well since this eliminates contorted efforts to redefine > PATH. > > Probably not a general solution for bash (though a --with-rbash-PATH= > configure option would be nice), but exactly what we want for an appliance. > > > The initial default 'safe' commands are: > ============== > pbx4 [staff] $ ls -1 /usr/rbin/ > arp > clear > date > df > fping > fping6 > host > htop > ifconfig > ip > ls > netstat > nslookup > ping > ping6 > ps > pwd > ss > top > traceroute > traceroute6 > uname > uptime > whoami > whois > ============== > > Lonnie > > > Of course that was just like waving a red flag in front of a bull... and > we took to the challenge with gusto. > > PS: David, see if you can break out :-) > > > > On Feb 13, 2017, at 11:14 PM, Lonnie Abelbeck <li...@lo...> > wrote: > > > Devs, > > > > I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in > CLI tab, ssh session, and console tty. > > > > The only issue is "ssh staff@pbx remote_command", the remote_command is > executed under /bin/rbash but not with the desired $PATH. > > > > If only we could set a compile time option to bash to force > PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. > > > > If only there was a /etc/ssh/sshd_config option to ignore any passed > remote_command for "Match User staff". > > > > Hmmm... > > > > Lonnie > > > > > > On Feb 13, 2017, at 4:24 PM, Michael Knill <michael.knill@ipcsolutions. > com.au> wrote: > > > >> +1 from me (obviously) And I can add and remove users/executables if > required. > >> > >> Maybe a couple of others: > >> traceroute > >> nslookup > >> arp > >> > >> I wont have the need for ls or the ability to read files, basically > just network and system tools. > >> Others may have different requirements? > >> > >> Regards > >> Michael Knill > >> > >> -----Original Message----- > >> From: Michael Keuter <li...@mk...> > >> Reply-To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > >> Date: Tuesday, 14 February 2017 at 9:01 AM > >> To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > >> Subject: Re: [Astlinux-devel] Restricting access to partners > >> > >> Hi Lonnie, > >> > >> I really like the idea with rbash. I also would have uses for that. > >> Most of that (including the user) could be predefined in our > buildsystem, and if someone would need that, it could be used right away. > >> > >> Sent from a mobile device. > >> > >> Michael Keuter > >> > >>> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck < > li...@lo...>: > >>> > >>> Hi Michael, > >>> > >>> I've been playing with rbash, and I think this could be generally > useful for us. > >>> > >>> I looked over the "Escaping Restricted Linux Shells" to limit our > /usr/rbin executables to keep it as secure as possible. > >>> > >>> The root user could add a 'rbash' user 'staff' > >>> -- > >>> adduser -s /bin/rbash staff > >>> -- > >>> > >>> The search path in /etc/profile (if SHELL is /bin/rbash) would be set > to: > >>> -- > >>> PATH=/usr/rbin:/mnt/kd/rbin > >>> -- > >>> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* > the restrictions are enabled. > >>> > >>> Then the /usr/rbin directory could contain symlinks for: > >>> -- > >>> /bin/ls > >>> /bin/netstat > >>> /bin/ping > >>> /bin/uname > >>> > >>> /usr/bin/clear > >>> /usr/bin/htop > >>> /usr/bin/top > >>> > >>> /sbin/ifconfig > >>> /sbin/ip > >>> /sbin/ss > >>> > >>> /usr/sbin/fping > >>> /usr/sbin/iftop > >>> -- > >>> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head > and tail ? Any others ? > >>> > >>> This should go in quite cleanly, mostly build system stuff. > >>> > >>> Lonnie > >>> > >>> > >>> > >>>> On Feb 13, 2017, at 3:31 PM, Michael Knill < > mic...@ip...> wrote: > >>>> > >>>> Hi thanks Lonnie > >>>> > >>>> Yes I completely agree with you and I am actually more concerned > about the temptation of people to tinker rather than loss of my IP. > >>>> Im moving down the route of rbash accessed from the shellinabox > interface which should be fairly simple to set up. Yes I realise that it > can be bypassed but a lock on the door wont prevent someone smashing the > window, but one is more malicious than the other. > >>>> Having the symlink in build will mean I don't need to do it so Im > interested ☺ > >>>> > >>>> Regards > >>>> Michael Knill > >>>> > >>>> -----Original Message----- > >>>> From: Lonnie Abelbeck <li...@lo...> > >>>> Reply-To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > >>>> Date: Tuesday, 14 February 2017 at 2:14 AM > >>>> To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > >>>> Subject: Re: [Astlinux-devel] Restricting access to partners > >>>> > >>>> A couple thoughts ... > >>>> > >>>> 1) If your business partner has physical access to your > pre-configured AstLinux appliance, then all bets are off, without > encrypting the filesystem your files (intellectual property) can be viewed. > >>>> > >>>> 1a) It took Apple years to accomplish this in iOS, included custom > hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. > >>>> > >>>> > >>>>> I would actually like to restrict them to just being able to run > certain scripts or bin files. > >>>>> Is this reasonable easy to do? > >>>> > >>>> 2) Bash can be restricted ... > >>>> https://www.gnu.org/software/bash/manual/html_node/The- > Restricted-Shell.html > >>>> > >>>> But can be escaped as well > >>>> https://pen-testing.sans.org/blog/2012/06/06/escaping- > restricted-linux-shells > >>>> > >>>> Additionally generating a list of "allowed" commands (in custom > $PATH) could be difficult to be both useful and restrictive. > >>>> > >>>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time > if anyone finds this useful. > >>>> > >>>> > >>>> 3) IMHO, the best way for a business partnership to work is when the > partners can trust each other and any partner can only "loose" if they > betray that trust. Legal agreements may be a part of this. > >>>> > >>>> > >>>> Lonnie > >>>> > >>>> > >>>> > >>>>> On Feb 13, 2017, at 3:54 AM, Michael Knill < > mic...@ip...> wrote: > >>>>> > >>>>> Hi Devs > >>>>> > >>>>> I now have a small business partner who is rolling out my systems. > >>>>> They want to use the Astlinux appliance at the edge but they are > concerned that there is limited access to perform network tests etc. > >>>>> I don't want to give them full CLI access as I don't just want to > protect my IP but I am also concerned they will be tempted to play. > >>>>> From what I see, there are a couple of options: > >>>>> 1) Add the network tools to the Web GUI - Difficult and time > consuming and not good user experience > >>>>> 2) Add or use a restricted shell – Im not sure how to do this > >>>>> 3) Some other idea > >>>>> > >>>> > >>>>> I would actually like to restrict them to just being able to run > certain scripts or bin files. > >>>>> Is this reasonable easy to do? > >>>> > >>>>> I would love some ideas. > >>>>> Thanks so much. > >>>>> > >>>>> Regards > >>>>> Michael Knill > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2017-02-14 21:50:37
|
Awesome thanks Lonnie Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Wednesday, 15 February 2017 at 5:11 AM To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Restricting access to partners Update, I committed rbash support, it went in quite cleanly. https://sourceforge.net/p/astlinux/code/8161/ A non-root user with /bin/rbash shell can be accessed via the CLI tab, ssh session, and console tty. Obviously this needs testing. > If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. After studying the bash code, a one-line patch fixes the sshd problem by setting PATH just before it makes it read-only for restricted mode. This is more secure as well since this eliminates contorted efforts to redefine PATH. Probably not a general solution for bash (though a --with-rbash-PATH= configure option would be nice), but exactly what we want for an appliance. The initial default 'safe' commands are: ============== pbx4 [staff] $ ls -1 /usr/rbin/ arp clear date df fping fping6 host htop ifconfig ip ls netstat nslookup ping ping6 ps pwd ss top traceroute traceroute6 uname uptime whoami whois ============== Lonnie > Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. PS: David, see if you can break out :-) On Feb 13, 2017, at 11:14 PM, Lonnie Abelbeck <li...@lo...> wrote: > Devs, > > I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in CLI tab, ssh session, and console tty. > > The only issue is "ssh staff@pbx remote_command", the remote_command is executed under /bin/rbash but not with the desired $PATH. > > If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. > > If only there was a /etc/ssh/sshd_config option to ignore any passed remote_command for "Match User staff". > > Hmmm... > > Lonnie > > > On Feb 13, 2017, at 4:24 PM, Michael Knill <mic...@ip...> wrote: > >> +1 from me (obviously) And I can add and remove users/executables if required. >> >> Maybe a couple of others: >> traceroute >> nslookup >> arp >> >> I wont have the need for ls or the ability to read files, basically just network and system tools. >> Others may have different requirements? >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux Developers Mailing List <ast...@li...> >> Date: Tuesday, 14 February 2017 at 9:01 AM >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] Restricting access to partners >> >> Hi Lonnie, >> >> I really like the idea with rbash. I also would have uses for that. >> Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. >> >> Sent from a mobile device. >> >> Michael Keuter >> >>> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Hi Michael, >>> >>> I've been playing with rbash, and I think this could be generally useful for us. >>> >>> I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. >>> >>> The root user could add a 'rbash' user 'staff' >>> -- >>> adduser -s /bin/rbash staff >>> -- >>> >>> The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: >>> -- >>> PATH=/usr/rbin:/mnt/kd/rbin >>> -- >>> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. >>> >>> Then the /usr/rbin directory could contain symlinks for: >>> -- >>> /bin/ls >>> /bin/netstat >>> /bin/ping >>> /bin/uname >>> >>> /usr/bin/clear >>> /usr/bin/htop >>> /usr/bin/top >>> >>> /sbin/ifconfig >>> /sbin/ip >>> /sbin/ss >>> >>> /usr/sbin/fping >>> /usr/sbin/iftop >>> -- >>> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? >>> >>> This should go in quite cleanly, mostly build system stuff. >>> >>> Lonnie >>> >>> >>> >>>> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi thanks Lonnie >>>> >>>> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >>>> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >>>> Having the symlink in build will mean I don't need to do it so Im interested ☺ >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux Developers Mailing List <ast...@li...> >>>> Date: Tuesday, 14 February 2017 at 2:14 AM >>>> To: AstLinux Developers Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-devel] Restricting access to partners >>>> >>>> A couple thoughts ... >>>> >>>> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >>>> >>>> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >>>> >>>> >>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>>> Is this reasonable easy to do? >>>> >>>> 2) Bash can be restricted ... >>>> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >>>> >>>> But can be escaped as well >>>> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >>>> >>>> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >>>> >>>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >>>> >>>> >>>> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >>>> >>>> >>>> Lonnie >>>> >>>> >>>> >>>>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Hi Devs >>>>> >>>>> I now have a small business partner who is rolling out my systems. >>>>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>>>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>>>> From what I see, there are a couple of options: >>>>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>>>> 2) Add or use a restricted shell – Im not sure how to do this >>>>> 3) Some other idea >>>>> >>>> >>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>>> Is this reasonable easy to do? >>>> >>>>> I would love some ideas. >>>>> Thanks so much. >>>>> >>>>> Regards >>>>> Michael Knill ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-14 18:11:45
|
Update, I committed rbash support, it went in quite cleanly. https://sourceforge.net/p/astlinux/code/8161/ A non-root user with /bin/rbash shell can be accessed via the CLI tab, ssh session, and console tty. Obviously this needs testing. > If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. After studying the bash code, a one-line patch fixes the sshd problem by setting PATH just before it makes it read-only for restricted mode. This is more secure as well since this eliminates contorted efforts to redefine PATH. Probably not a general solution for bash (though a --with-rbash-PATH= configure option would be nice), but exactly what we want for an appliance. The initial default 'safe' commands are: ============== pbx4 [staff] $ ls -1 /usr/rbin/ arp clear date df fping fping6 host htop ifconfig ip ls netstat nslookup ping ping6 ps pwd ss top traceroute traceroute6 uname uptime whoami whois ============== Lonnie > Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. PS: David, see if you can break out :-) On Feb 13, 2017, at 11:14 PM, Lonnie Abelbeck <li...@lo...> wrote: > Devs, > > I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in CLI tab, ssh session, and console tty. > > The only issue is "ssh staff@pbx remote_command", the remote_command is executed under /bin/rbash but not with the desired $PATH. > > If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. > > If only there was a /etc/ssh/sshd_config option to ignore any passed remote_command for "Match User staff". > > Hmmm... > > Lonnie > > > On Feb 13, 2017, at 4:24 PM, Michael Knill <mic...@ip...> wrote: > >> +1 from me (obviously) And I can add and remove users/executables if required. >> >> Maybe a couple of others: >> traceroute >> nslookup >> arp >> >> I wont have the need for ls or the ability to read files, basically just network and system tools. >> Others may have different requirements? >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux Developers Mailing List <ast...@li...> >> Date: Tuesday, 14 February 2017 at 9:01 AM >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] Restricting access to partners >> >> Hi Lonnie, >> >> I really like the idea with rbash. I also would have uses for that. >> Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. >> >> Sent from a mobile device. >> >> Michael Keuter >> >>> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Hi Michael, >>> >>> I've been playing with rbash, and I think this could be generally useful for us. >>> >>> I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. >>> >>> The root user could add a 'rbash' user 'staff' >>> -- >>> adduser -s /bin/rbash staff >>> -- >>> >>> The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: >>> -- >>> PATH=/usr/rbin:/mnt/kd/rbin >>> -- >>> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. >>> >>> Then the /usr/rbin directory could contain symlinks for: >>> -- >>> /bin/ls >>> /bin/netstat >>> /bin/ping >>> /bin/uname >>> >>> /usr/bin/clear >>> /usr/bin/htop >>> /usr/bin/top >>> >>> /sbin/ifconfig >>> /sbin/ip >>> /sbin/ss >>> >>> /usr/sbin/fping >>> /usr/sbin/iftop >>> -- >>> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? >>> >>> This should go in quite cleanly, mostly build system stuff. >>> >>> Lonnie >>> >>> >>> >>>> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi thanks Lonnie >>>> >>>> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >>>> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >>>> Having the symlink in build will mean I don't need to do it so Im interested ☺ >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux Developers Mailing List <ast...@li...> >>>> Date: Tuesday, 14 February 2017 at 2:14 AM >>>> To: AstLinux Developers Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-devel] Restricting access to partners >>>> >>>> A couple thoughts ... >>>> >>>> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >>>> >>>> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >>>> >>>> >>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>>> Is this reasonable easy to do? >>>> >>>> 2) Bash can be restricted ... >>>> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >>>> >>>> But can be escaped as well >>>> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >>>> >>>> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >>>> >>>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >>>> >>>> >>>> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >>>> >>>> >>>> Lonnie >>>> >>>> >>>> >>>>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Hi Devs >>>>> >>>>> I now have a small business partner who is rolling out my systems. >>>>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>>>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>>>> From what I see, there are a couple of options: >>>>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>>>> 2) Add or use a restricted shell – Im not sure how to do this >>>>> 3) Some other idea >>>>> >>>> >>>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>>> Is this reasonable easy to do? >>>> >>>>> I would love some ideas. >>>>> Thanks so much. >>>>> >>>>> Regards >>>>> Michael Knill |
|
From: Michael K. <mic...@ip...> - 2017-02-14 07:14:48
|
If you restrict the staff user to use SSH Keys only, you can add the allowed commands in authorized_keys. This could be a script that does what you want including setting the correct path. Or you could have no SSH for the staff user and use console and CLI only (what I will be doing)? Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Tuesday, 14 February 2017 at 4:14 PM To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Restricting access to partners Devs, I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in CLI tab, ssh session, and console tty. The only issue is "ssh staff@pbx remote_command", the remote_command is executed under /bin/rbash but not with the desired $PATH. If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. If only there was a /etc/ssh/sshd_config option to ignore any passed remote_command for "Match User staff". Hmmm... Lonnie On Feb 13, 2017, at 4:24 PM, Michael Knill <mic...@ip...> wrote: > +1 from me (obviously) And I can add and remove users/executables if required. > > Maybe a couple of others: > traceroute > nslookup > arp > > I wont have the need for ls or the ability to read files, basically just network and system tools. > Others may have different requirements? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Tuesday, 14 February 2017 at 9:01 AM > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Restricting access to partners > > Hi Lonnie, > > I really like the idea with rbash. I also would have uses for that. > Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. > > Sent from a mobile device. > > Michael Keuter > >> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: >> >> Hi Michael, >> >> I've been playing with rbash, and I think this could be generally useful for us. >> >> I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. >> >> The root user could add a 'rbash' user 'staff' >> -- >> adduser -s /bin/rbash staff >> -- >> >> The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: >> -- >> PATH=/usr/rbin:/mnt/kd/rbin >> -- >> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. >> >> Then the /usr/rbin directory could contain symlinks for: >> -- >> /bin/ls >> /bin/netstat >> /bin/ping >> /bin/uname >> >> /usr/bin/clear >> /usr/bin/htop >> /usr/bin/top >> >> /sbin/ifconfig >> /sbin/ip >> /sbin/ss >> >> /usr/sbin/fping >> /usr/sbin/iftop >> -- >> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? >> >> This should go in quite cleanly, mostly build system stuff. >> >> Lonnie >> >> >> >>> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi thanks Lonnie >>> >>> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >>> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >>> Having the symlink in build will mean I don't need to do it so Im interested ☺ >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux Developers Mailing List <ast...@li...> >>> Date: Tuesday, 14 February 2017 at 2:14 AM >>> To: AstLinux Developers Mailing List <ast...@li...> >>> Subject: Re: [Astlinux-devel] Restricting access to partners >>> >>> A couple thoughts ... >>> >>> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >>> >>> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >>> >>> >>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>> Is this reasonable easy to do? >>> >>> 2) Bash can be restricted ... >>> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >>> >>> But can be escaped as well >>> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >>> >>> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >>> >>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >>> >>> >>> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >>> >>> >>> Lonnie >>> >>> >>> >>>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi Devs >>>> >>>> I now have a small business partner who is rolling out my systems. >>>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>>> From what I see, there are a couple of options: >>>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>>> 2) Add or use a restricted shell – Im not sure how to do this >>>> 3) Some other idea >>>> >>> >>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>> Is this reasonable easy to do? >>> >>>> I would love some ideas. >>>> Thanks so much. >>>> >>>> Regards >>>> Michael Knill >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-14 05:14:41
|
Devs, I have /bin/rbash working with PATH="/usr/rbin:/mnt/kd/rbin", works in CLI tab, ssh session, and console tty. The only issue is "ssh staff@pbx remote_command", the remote_command is executed under /bin/rbash but not with the desired $PATH. If only we could set a compile time option to bash to force PATH="/usr/rbin:/mnt/kd/rbin" when the restrictive shell is enabled. If only there was a /etc/ssh/sshd_config option to ignore any passed remote_command for "Match User staff". Hmmm... Lonnie On Feb 13, 2017, at 4:24 PM, Michael Knill <mic...@ip...> wrote: > +1 from me (obviously) And I can add and remove users/executables if required. > > Maybe a couple of others: > traceroute > nslookup > arp > > I wont have the need for ls or the ability to read files, basically just network and system tools. > Others may have different requirements? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Tuesday, 14 February 2017 at 9:01 AM > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Restricting access to partners > > Hi Lonnie, > > I really like the idea with rbash. I also would have uses for that. > Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. > > Sent from a mobile device. > > Michael Keuter > >> Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: >> >> Hi Michael, >> >> I've been playing with rbash, and I think this could be generally useful for us. >> >> I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. >> >> The root user could add a 'rbash' user 'staff' >> -- >> adduser -s /bin/rbash staff >> -- >> >> The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: >> -- >> PATH=/usr/rbin:/mnt/kd/rbin >> -- >> BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. >> >> Then the /usr/rbin directory could contain symlinks for: >> -- >> /bin/ls >> /bin/netstat >> /bin/ping >> /bin/uname >> >> /usr/bin/clear >> /usr/bin/htop >> /usr/bin/top >> >> /sbin/ifconfig >> /sbin/ip >> /sbin/ss >> >> /usr/sbin/fping >> /usr/sbin/iftop >> -- >> If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? >> >> This should go in quite cleanly, mostly build system stuff. >> >> Lonnie >> >> >> >>> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi thanks Lonnie >>> >>> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >>> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >>> Having the symlink in build will mean I don't need to do it so Im interested ☺ >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux Developers Mailing List <ast...@li...> >>> Date: Tuesday, 14 February 2017 at 2:14 AM >>> To: AstLinux Developers Mailing List <ast...@li...> >>> Subject: Re: [Astlinux-devel] Restricting access to partners >>> >>> A couple thoughts ... >>> >>> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >>> >>> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >>> >>> >>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>> Is this reasonable easy to do? >>> >>> 2) Bash can be restricted ... >>> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >>> >>> But can be escaped as well >>> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >>> >>> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >>> >>> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >>> >>> >>> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >>> >>> >>> Lonnie >>> >>> >>> >>>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi Devs >>>> >>>> I now have a small business partner who is rolling out my systems. >>>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>>> From what I see, there are a couple of options: >>>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>>> 2) Add or use a restricted shell – Im not sure how to do this >>>> 3) Some other idea >>>> >>> >>>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>>> Is this reasonable easy to do? >>> >>>> I would love some ideas. >>>> Thanks so much. >>>> >>>> Regards >>>> Michael Knill >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2017-02-13 22:24:40
|
+1 from me (obviously) And I can add and remove users/executables if required. Maybe a couple of others: traceroute nslookup arp I wont have the need for ls or the ability to read files, basically just network and system tools. Others may have different requirements? Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Tuesday, 14 February 2017 at 9:01 AM To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Restricting access to partners Hi Lonnie, I really like the idea with rbash. I also would have uses for that. Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. Sent from a mobile device. Michael Keuter > Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael, > > I've been playing with rbash, and I think this could be generally useful for us. > > I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. > > The root user could add a 'rbash' user 'staff' > -- > adduser -s /bin/rbash staff > -- > > The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: > -- > PATH=/usr/rbin:/mnt/kd/rbin > -- > BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. > > Then the /usr/rbin directory could contain symlinks for: > -- > /bin/ls > /bin/netstat > /bin/ping > /bin/uname > > /usr/bin/clear > /usr/bin/htop > /usr/bin/top > > /sbin/ifconfig > /sbin/ip > /sbin/ss > > /usr/sbin/fping > /usr/sbin/iftop > -- > If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? > > This should go in quite cleanly, mostly build system stuff. > > Lonnie > > > >> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi thanks Lonnie >> >> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >> Having the symlink in build will mean I don't need to do it so Im interested ☺ >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux Developers Mailing List <ast...@li...> >> Date: Tuesday, 14 February 2017 at 2:14 AM >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] Restricting access to partners >> >> A couple thoughts ... >> >> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >> >> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >> >> >>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>> Is this reasonable easy to do? >> >> 2) Bash can be restricted ... >> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >> >> But can be escaped as well >> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >> >> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >> >> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >> >> >> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >> >> >> Lonnie >> >> >> >>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Devs >>> >>> I now have a small business partner who is rolling out my systems. >>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>> From what I see, there are a couple of options: >>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>> 2) Add or use a restricted shell – Im not sure how to do this >>> 3) Some other idea >>> >> >>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>> Is this reasonable easy to do? >> >>> I would love some ideas. >>> Thanks so much. >>> >>> Regards >>> Michael Knill >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2017-02-13 22:22:11
|
This discussion reminds me of my freshman year in university. Many many years ago (lets just say it was before the days of every student having their own PC/Laptop). We were assigned user accounts on a central system (all CLI, no such thing as a GUI in those days) and the computer science department put all freshmen into a "restricted" environment which basically meant that we could only execute certain commands... those we might be expected to use for our course work. Of course that was just like waving a red flag in front of a bull... and we took to the challenge with gusto. What ensued was a year long game of cat and mouse, and us mice were very smart people, finding loophole after loophole. Unfortunately for them one of the commands we had to be able to use was the language compiler (it may have been Pascal, don't think it was C). And with that we found that we could call system APIs a plenty. So while it was easy to cut off CLI commands, they found it much much harder to cut of API access. And we had a flourishing "business" in writing our own CLI's that could run restricted commands simply by replicating the system API calls they would make. This was huge fun for us freshmen, and I think for the CS department as well. They learnt a lot and we learnt a lot. David On Mon, Feb 13, 2017 at 4:31 PM, Michael Knill < mic...@ip...> wrote: > Hi thanks Lonnie > > Yes I completely agree with you and I am actually more concerned about the > temptation of people to tinker rather than loss of my IP. > Im moving down the route of rbash accessed from the shellinabox interface > which should be fairly simple to set up. Yes I realise that it can be > bypassed but a lock on the door wont prevent someone smashing the window, > but one is more malicious than the other. > Having the symlink in build will mean I don't need to do it so Im > interested ☺ > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > Date: Tuesday, 14 February 2017 at 2:14 AM > To: AstLinux Developers Mailing List <ast...@li... > > > Subject: Re: [Astlinux-devel] Restricting access to partners > > A couple thoughts ... > > 1) If your business partner has physical access to your pre-configured > AstLinux appliance, then all bets are off, without encrypting the > filesystem your files (intellectual property) can be viewed. > > 1a) It took Apple years to accomplish this in iOS, included custom > hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. > > > > I would actually like to restrict them to just being able to run certain > scripts or bin files. > > Is this reasonable easy to do? > > 2) Bash can be restricted ... > https://www.gnu.org/software/bash/manual/html_node/The- > Restricted-Shell.html > > But can be escaped as well > https://pen-testing.sans.org/blog/2012/06/06/escaping- > restricted-linux-shells > > Additionally generating a list of "allowed" commands (in custom $PATH) > could be difficult to be both useful and restrictive. > > BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if > anyone finds this useful. > > > 3) IMHO, the best way for a business partnership to work is when the > partners can trust each other and any partner can only "loose" if they > betray that trust. Legal agreements may be a part of this. > > > Lonnie > > > > On Feb 13, 2017, at 3:54 AM, Michael Knill <michael.knill@ipcsolutions. > com.au> wrote: > > > Hi Devs > > > > I now have a small business partner who is rolling out my systems. > > They want to use the Astlinux appliance at the edge but they are > concerned that there is limited access to perform network tests etc. > > I don't want to give them full CLI access as I don't just want to > protect my IP but I am also concerned they will be tempted to play. > > From what I see, there are a couple of options: > > 1) Add the network tools to the Web GUI - Difficult and time > consuming and not good user experience > > 2) Add or use a restricted shell – Im not sure how to do this > > 3) Some other idea > > > > > I would actually like to restrict them to just being able to run certain > scripts or bin files. > > Is this reasonable easy to do? > > > I would love some ideas. > > Thanks so much. > > > > Regards > > Michael Knill > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Michael K. <li...@mk...> - 2017-02-13 22:01:19
|
Hi Lonnie, I really like the idea with rbash. I also would have uses for that. Most of that (including the user) could be predefined in our buildsystem, and if someone would need that, it could be used right away. Sent from a mobile device. Michael Keuter > Am 13.02.2017 um 22:52 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael, > > I've been playing with rbash, and I think this could be generally useful for us. > > I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. > > The root user could add a 'rbash' user 'staff' > -- > adduser -s /bin/rbash staff > -- > > The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: > -- > PATH=/usr/rbin:/mnt/kd/rbin > -- > BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. > > Then the /usr/rbin directory could contain symlinks for: > -- > /bin/ls > /bin/netstat > /bin/ping > /bin/uname > > /usr/bin/clear > /usr/bin/htop > /usr/bin/top > > /sbin/ifconfig > /sbin/ip > /sbin/ss > > /usr/sbin/fping > /usr/sbin/iftop > -- > If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? > > This should go in quite cleanly, mostly build system stuff. > > Lonnie > > > >> On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi thanks Lonnie >> >> Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. >> Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. >> Having the symlink in build will mean I don't need to do it so Im interested ☺ >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux Developers Mailing List <ast...@li...> >> Date: Tuesday, 14 February 2017 at 2:14 AM >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] Restricting access to partners >> >> A couple thoughts ... >> >> 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. >> >> 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. >> >> >>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>> Is this reasonable easy to do? >> >> 2) Bash can be restricted ... >> https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html >> >> But can be escaped as well >> https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells >> >> Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. >> >> BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. >> >> >> 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. >> >> >> Lonnie >> >> >> >>> On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Devs >>> >>> I now have a small business partner who is rolling out my systems. >>> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >>> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >>> From what I see, there are a couple of options: >>> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >>> 2) Add or use a restricted shell – Im not sure how to do this >>> 3) Some other idea >>> >> >>> I would actually like to restrict them to just being able to run certain scripts or bin files. >>> Is this reasonable easy to do? >> >>> I would love some ideas. >>> Thanks so much. >>> >>> Regards >>> Michael Knill >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-13 21:52:39
|
Hi Michael, I've been playing with rbash, and I think this could be generally useful for us. I looked over the "Escaping Restricted Linux Shells" to limit our /usr/rbin executables to keep it as secure as possible. The root user could add a 'rbash' user 'staff' -- adduser -s /bin/rbash staff -- The search path in /etc/profile (if SHELL is /bin/rbash) would be set to: -- PATH=/usr/rbin:/mnt/kd/rbin -- BTW, key point the /etc/profile is executed by '/bin/rbash' *before* the restrictions are enabled. Then the /usr/rbin directory could contain symlinks for: -- /bin/ls /bin/netstat /bin/ping /bin/uname /usr/bin/clear /usr/bin/htop /usr/bin/top /sbin/ifconfig /sbin/ip /sbin/ss /usr/sbin/fping /usr/sbin/iftop -- If reading files is OK, Possibly also "/bin/cat" ? "/bin/grep" ? head and tail ? Any others ? This should go in quite cleanly, mostly build system stuff. Lonnie On Feb 13, 2017, at 3:31 PM, Michael Knill <mic...@ip...> wrote: > Hi thanks Lonnie > > Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. > Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. > Having the symlink in build will mean I don't need to do it so Im interested ☺ > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Tuesday, 14 February 2017 at 2:14 AM > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Restricting access to partners > > A couple thoughts ... > > 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. > > 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. > > >> I would actually like to restrict them to just being able to run certain scripts or bin files. >> Is this reasonable easy to do? > > 2) Bash can be restricted ... > https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html > > But can be escaped as well > https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells > > Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. > > BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. > > > 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. > > > Lonnie > > > > On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: > >> Hi Devs >> >> I now have a small business partner who is rolling out my systems. >> They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. >> I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. >> From what I see, there are a couple of options: >> 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience >> 2) Add or use a restricted shell – Im not sure how to do this >> 3) Some other idea >> > >> I would actually like to restrict them to just being able to run certain scripts or bin files. >> Is this reasonable easy to do? > >> I would love some ideas. >> Thanks so much. >> >> Regards >> Michael Knill > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2017-02-13 21:32:10
|
Hi thanks Lonnie Yes I completely agree with you and I am actually more concerned about the temptation of people to tinker rather than loss of my IP. Im moving down the route of rbash accessed from the shellinabox interface which should be fairly simple to set up. Yes I realise that it can be bypassed but a lock on the door wont prevent someone smashing the window, but one is more malicious than the other. Having the symlink in build will mean I don't need to do it so Im interested ☺ Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Tuesday, 14 February 2017 at 2:14 AM To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Restricting access to partners A couple thoughts ... 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. > I would actually like to restrict them to just being able to run certain scripts or bin files. > Is this reasonable easy to do? 2) Bash can be restricted ... https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html But can be escaped as well https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. Lonnie On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: > Hi Devs > > I now have a small business partner who is rolling out my systems. > They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. > I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. > From what I see, there are a couple of options: > 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience > 2) Add or use a restricted shell – Im not sure how to do this > 3) Some other idea > > I would actually like to restrict them to just being able to run certain scripts or bin files. > Is this reasonable easy to do? > I would love some ideas. > Thanks so much. > > Regards > Michael Knill ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2017-02-13 15:14:21
|
A couple thoughts ... 1) If your business partner has physical access to your pre-configured AstLinux appliance, then all bets are off, without encrypting the filesystem your files (intellectual property) can be viewed. 1a) It took Apple years to accomplish this in iOS, included custom hardware, a Trusted Platform Module, per-user signed firmware, etc. etc. > I would actually like to restrict them to just being able to run certain scripts or bin files. > Is this reasonable easy to do? 2) Bash can be restricted ... https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html But can be escaped as well https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells Additionally generating a list of "allowed" commands (in custom $PATH) could be difficult to be both useful and restrictive. BTW, we could add the "ln -s bash /bin/rbash" symlink at build-time if anyone finds this useful. 3) IMHO, the best way for a business partnership to work is when the partners can trust each other and any partner can only "loose" if they betray that trust. Legal agreements may be a part of this. Lonnie On Feb 13, 2017, at 3:54 AM, Michael Knill <mic...@ip...> wrote: > Hi Devs > > I now have a small business partner who is rolling out my systems. > They want to use the Astlinux appliance at the edge but they are concerned that there is limited access to perform network tests etc. > I don't want to give them full CLI access as I don't just want to protect my IP but I am also concerned they will be tempted to play. > From what I see, there are a couple of options: > 1) Add the network tools to the Web GUI - Difficult and time consuming and not good user experience > 2) Add or use a restricted shell – Im not sure how to do this > 3) Some other idea > > I would actually like to restrict them to just being able to run certain scripts or bin files. > Is this reasonable easy to do? > I would love some ideas. > Thanks so much. > > Regards > Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2017-02-13 14:05:58
|
Followup, It appears previously Sourceforge offered a "astlinux-commits" mailing list, this list is no longer being added to by Sourceforge. As noted below, this line ... -- AstLinux Code Everything (check) -- should appear on this page to receive AstLinux code commit emails: https://sourceforge.net/auth/subscriptions/ Alternatively, while logged into your Sourceforge account, you can go to this link: https://sourceforge.net/p/astlinux/code/HEAD/tree/ Notice the little "envelope" icon to the right of "History" ... Clicking on the "envelope" icon will toggle subscribing to AstLinux code commit emails or not. Lonnie On Feb 12, 2017, at 8:38 AM, Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > If you were previously subscribed to Sourceforge's "AstLinux - Code" to receive commit emails, it stopped working a few days ago, and you need to re-subscribe (checkbox and {Save}) to get commit emails. > > https://sourceforge.net/auth/subscriptions/ > > BTW, the commit emails are of a very different format (more like GitHub's now). > > Lonnie |
28 messages has been excluded from this view by a project administrator.
